Radiocommunication module hosting and executing a client software, and corresponding method for implementing a driving client software

ABSTRACT

The invention concerns a radiocommunication module, of the type hosting and executing a main software providing in particular radiocommunication functions. The main software comprises means for executing drive controls, sent to the main software and belonging to a predetermined set of drive controls. The invention is characterised in that the radiocommunication module further hosts and executes at least a client software, called onboard client software. The onboard client software and the main software comprise means enabling the onboard client software acts at least as one of the following: a driver client software, sending drive controls to the main software, and receiving from the main software responses, resulting from the execution of some of the drive controls; a supervising client software, managing the execution if the drive controls sent by a driver client software, called external client software, hosted and executed by a third party equipment co-operating with the radiocommunication module.

CROSS-REFERENCE TO RELATED APPLICATION

This Application is a Section 371 National Stage Application ofInternational Application No. PCT/FR02/01024, filed Mar. 22, 2002 andpublished as WO 02/078375 on Oct. 3, 2002, not in English.

FIELD OF INVENTION

The domain of this invention is radiocommunication systems, andparticularly but not exclusively the GSM (Global System for MobileCommunications) standard, DCS 1800 (Digital Cellular System 1800 MHz),PCS 1900 (Personal Communication system), GPRS (General Packet RadioService) or UMTS (Universal Mobile Telecommunication System).

BACKGROUND OF THE INVENTION

More precisely, the invention relates to a radiocommunication module.Remember that the radiocommunication module is an essential element of aradiotelephone. It hosts and executes a main software (commonly called“radiocommunication software” or “GSM software”) that in particularperforms wireless communication functions (radiocommunication) andcontrols various other hardware elements (screen, keyboard, loudspeaker,etc.) of the radiotelephone.

Normally (first application), the radiocommunication module is includedin a terminal (or ME for “Mobile Equipment”) that cooperates with a SIM(Subscriber Identity Module) card.

Other applications are now envisaged for the above mentionedradiocommunication module.

In particular, it has been proposed to integrate the radiocommunicationmodule in devices other than radiocommunication terminals but that stillrequire a wireless communication function (second application). Forexample, telemetry devices (for reading meters), alarm devices or bankcard readers.

It has also been proposed to supply the radiocommunication module inindependent form (third application); it is then qualified as a modem.This type of modem does not contain any hardware man-machine interfaceelement (screen, keyboard, loudspeaker, etc.). It is designed tocooperate with a terminal equipment (supporting a client software), thatdoes have hardware man-machine interface elements. In particular, butnot exclusively, the terminal equipment may be a microcomputer. Ingeneral, the terminal equipment hosts and executes a client driversoftware that controls the radiocommunication module, using a set ofdriver commands in the AT format. The AT (for ATtention command)commands enable the Terminal Equipment (TE) to request theradiocommunication terminal to which it is connected to perform somepredetermined actions. To achieve this, the main software (hosted on theradiocommunication module) comprises means of executing AT commands sentto it by the client driver software (hosted on the terminal equipment).

For further information about AT commands, refer firstly to the ETSI“GSM 07.05” and “GSM 07.07” standards, and secondly to the ITU-Trecommendation V25ter which are inserted herein by reference.

In general, a radiocommunication module can be driven by a terminalequipment using AT commands not only within the framework of the abovementioned third application (radiocommunication module forming a modem),but also within the context of the first and second applicationsmentioned above (radiocommunication module included in aradiocommunication terminal or other system).

In other words, regardless of what application is envisaged, theradiocommunication module may be driven by a terminal equipment withwhich it cooperates (usually through a serial link). In this case, aclient driver software (comprising a “client external application”),hosted and executed by the terminal equipment, sends AT commands to amain software, hosted and executed by the radiocommunication module, sothat the radiocommunication module can execute them.

As shown in FIG. 2, operation of the existing technique used forterminal equipment to drive a radiocommunication module may besummarized as follows:

-   -   step “1”: the client external application (client driver        software) 2 sends an AT command;    -   step “2”: the serial link 5 transmits the AT command to the AT        command execution means 4 included in the main software 3 hosted        and executed by the radiocommunication module 1;    -   step “3.”: the execution means 4 execute the AT command;    -   step “4”: after execution, the execution means 4 send an AT        response to the client external application 2;    -   step “5”: this response is sent through the serial link 5;    -   step “6”: the client external application 2 receives the        response.

Each of these steps is shown in FIG. 2 by a circle in which the numberof the step concerned is entered. The same convention is adopted in thefollowing figures related to this invention (and that are described indetail in the remainder of the description).

The existing technique for driving a radiocommunication module byterminal equipment has several disadvantages.

Firstly, it requires two sets of resources (processor and memory). Theradiocommunication module comprises a processor and a memory (first setof resources) and the terminal equipment also has a processor and amemory (second set of resources). Therefore, the existing techniquementioned above is expensive in terms of equipment and energyconsumption.

Another disadvantage of the above mentioned existing technique is thatthe radiocommunication module is entirely driven by the terminalequipment. The client driver software hosted on and executed by theterminal equipment is the “master”, while the main software hosted andexecuted by the radiocommunication module, is the “slave”.

The purpose of the invention is particularly to overcome thesedisadvantages with the state of the art.

More specifically, one purpose of this invention is to provide atechnique for driving a radiocommunication type module using a clientdriver software, that is simple and inexpensive (in terms of hardwareand energy consumption).

Another purpose of the invention is to provide such a driver techniqueenabling the radiocommunication module to supervise (and act upon) thedriving procedure, when driving is carried out by a terminal equipment.In other words, it is desired that the radiocommunication module doesnot only act as a slave.

SUMMARY OF THE INVENTION

These various objectives and others which will appear later are achievedusing a radiocommunication module, of the type hosting and executing amain software performing radiocommunication functions, the said mainsoftware comprising means of executing driver commands, sent to the mainsoftware by at least a client driver software, and belonging to apredetermined set of driver commands. According to the invention, theradiocommunication module also hosts and executes at least one clientsoftware, called the client embedded software. Furthermore, the clientembedded software and the main software comprise means of enabling theclient embedded software to perform at least one of the following tworoles:

-   -   the role of a client driver software sending driver commands to        the main software, and receiving responses from the main        software resulting from the execution of some of the driver        commands;    -   the role of a client supervision software, managing execution of        driver commands sent by a client driver software, called the        client external software, hosted and executed by terminal        equipment cooperating with the radiocommunication module.        Therefore, the general main principle of the invention consists        of hosting at least one client software on the        radiocommunication module, that can act as a client driver        software and/or as a client supervision software.

Thus, if the client embedded software acts as a client driver software,the radiocommunication module will operate independently andinexpensively. In this case, the radiocommunication module does not needto cooperate with any terminal equipment, and the main software and theclient driver software use the same resources (same processor and samememory).

This invention also provides a means of not limiting theradiocommunication module to acting as a slave towards the terminalequipment that executes the client driver software, in the case in whichthe client embedded software acts as client supervision software. Theclient supervision software executed by the radiocommunication modulemanages driver actions requested by the client driver software executedby the terminal equipment. Note that in this case, the client embeddedsoftware is additional to the state of the art configuration mentionedabove. However, this additional software is inexpensive since it usesthe same resources (processor and memory) as a main software also hostedon the radiocommunication module.

Advantageously, the following features are provided to enable the clientembedded software to act as client supervision software:

-   -   the main software comprises means of preparsing commands as a        function of a determined preparsing policy, so as to transmit        driver commands from the client external software to the client        embedded software and/or to execution means contained in the        main software;    -   the client embedded software includes means of processing driver        commands switched to it by the said preparsing means.

In this way, the client embedded software can:

-   -   either do nothing, the commands being sent only to the main        software, which executes them directly;    -   or filter commands transmitted to it without being executed by        the main software. For example, the client embedded software may        thus decide which commands should be executed by the main        software and the commands for which a response should be made        without execution, as a function of determined criteria;    -   or “spy” on commands of which it receives a copy, and which are        also executed directly by the main software.

Advantageously, to enable the client embedded software to act as clientsupervision software:

-   -   the main software comprises means of preparsing responses as a        function of a determined response preparsing policy, so as to        transmit responses resulting from the execution of some driver        commands by execution means included in the main software, to        the client embedded software and/or to the client external        software;    -   the client embedded software comprises means of processing        responses switched to it by the said response preparsing means.

In this way, the client embedded software can:

-   -   either not take any action, responses generated by the main        software being transmitted only to the client external software;    -   or filter responses transmitted to it without being transmitted        to the client external software. For example, the client        embedded software can thus decide what responses should be sent        to the client external software (modified or not modified) as a        function of defined criteria, and what responses should not be        transmitted to this client external software;    -   or “spy” on responses of which it receives a copy and which are        also sent directly to the client external software.

Preferably, the said main software comprises one main applicationparticularly based on a set of execution functions, each enabling theexecution of at least one of the said driver commands. The clientembedded software includes a client application, particularly based on aset of source functions, each enabling sending or receiving drivercommands or responses to driver commands, to or from the mainapplication. The main software and/or the said client embedded softwarecomprise an application interface used to interface the said sourcefunctions with the said execution functions.

The result is to limit development costs, due to the fact that theinterface application (also called the application interface library inthe following) can be used with different client applications, or evenwith different main software, once it has been developed.

In one preferred embodiment of the invention, the said set of drivercommands is a set of standard AT commands.

This enables fast development of the client embedded software, since ATcommands are well known and are already used for the development ofclient external software (hosted on the terminal equipment). This alsofacilitates development of a client software strongly based on anexisting client external software.

The invention also relates to a process for implementation of a clientsoftware for the control of a radio communication module, the saidradiocommunication module being of the type that hosts and executes amain software particularly performing radiocommunication functions, thesaid main software comprising means of executing driver commands sent tothe main software by the said client driver software and belonging to apredetermined set of driver commands. According to the invention, thesaid radiocommunication module hosts and also executes at least oneclient software, called the client embedded software. The clientembedded software and the main software dialogue with each other suchthat the client embedded software performs at least one of the followingtwo roles:

-   -   the role of the said client driver software to send driver        commands to the main software, and to receive responses        resulting from execution of some of the driver commands from the        main software;    -   the role of a client supervision software, managing execution of        driver commands sent by the said client driver software, the        said client driver software called the client external software        being hosted on and executed by terminal equipment cooperating        with the radiocommunication module.

BRIEF DESCRIPTION OF THE DRAWINGS

Other characteristics and advantages of the invention will become clearafter reading the following description of a preferred embodiment of theinvention given as a non-limitative example, and the attached drawings,in which:

FIG. 1 shows a simplified diagram of a particular embodiment of aradiocommunication module according to this invention;

FIG. 2 shows operation of the existing technique for driving aradiocommunication module by terminal equipment;

FIG. 3 illustrates the operation of a first embodiment of theradiocommunication module according to this invention, in which theclient embedded software acts as a client driver software;

FIGS. 4 to 7 each illustrate a mechanism for operation of a secondembodiment of the radiocommunication module according to this invention,in which the client embedded software acts as client supervisionsoftware, and more precisely:

FIG. 4 shows a command preparsing mechanism enabling the client embeddedsoftware to filter commands originating from the client externalsoftware;

FIG. 5 shows a variant embodiment of the command preparsing mechanism inFIG. 4, enabling the client embedded software to spy on commandsoriginating from the client external software;

FIG. 6 shows the response preparsing mechanism, enabling the clientembedded software to filter responses intended for the client externalsoftware;

FIG. 7 shows a variant of the response preparsing mechanism in FIG. 6,enabling the client embedded software to spy on responses intended forthe client external software.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Therefore, the invention relates to a radiocommunication module hostingand executing a main software and at least one client embedded software,using the same set of resources (processor and memory).

Conventionally, in particular the main software (for example a “GSMsoftware”) performs radiocommunication functions and comprises means ofexecuting driver commands (sent to it by a client driver software).

The client embedded software (concept specific to this invention), canact as:

-   -   a client driver software (first embodiment of the invention,        described below with reference to FIG. 3), and/or    -   a client supervision software (second embodiment of the        invention, described below in relation to FIGS. 4 to 7).

In the remainder of this description, it is assumed that the drivercommands are AT commands. However, it is clear that this invention isnot restricted to this type of driver command.

In the particular embodiment shown in FIG. 1, the main software 3comprises a main application 3 a based particularly on a set ofexecution functions, each enabling the execution of at least one ATcommand.

Furthermore, the client embedded software 6 comprises:

-   -   a client application 6 a, particularly based on a set of source        functions, each enabling sending AT commands to a main        application 1 a, or receiving AT commands from this application;    -   an interface application 6 b, enabling interfacing of source        functions (of the client main application 6 a) with execution        functions (of the main application 3 a).

The client embedded software 6 and the client main software 3communicate with each other by using API layers, references 61 and 31respectively. Note that the term API (Application Programming Interface)denotes an interface. It is a description of communication rulescorresponding to a particular functional assembly.

In the client embedded software 6, the API layer (embedded) 61comprises:

-   -   in the client embedded application 6 a:        -   an “Application Mandatory API” block forming an interface            describing functions that are to be defined in the client            embedded application;    -   in the interface application (or the interface application        library) 6 b: the following three blocks:    -   an “AT command API” block forming an interface describing access        to AT commands, this interface describes functions located in        the application interface library;    -   an “OS API” block forming an interface describing access to        operating system functions, this interface describes functions        located in the application interface library;    -   a “Standard API” block forming an interface describing the        access to standard functions, this interface describes functions        located in the application interface library.

In the main application 3 a in the main software 3, the API layer(exported) comprises:

-   -   an “AT command API” block, similar to the block with the same        name in the API layer 61 (embedded) in the client embedded        software 6;    -   an “OS API” block, similar to the block with the same name in        the API layer 61 (embedded) in the client embedded software 6.

The main application 3 a forms the kernel of the main software 3, andthe client application 6 a, and the interface application 6 b form thekernel 60 of the client embedded software 6.

The interface application 6 b is a software entity that enables adialogue between two independent software entities (or binary entitiesnamely the client application 6 a and the main application 3 a. Forexample, they are in the form of a library (already compiled).

The client embedded software and the main software each use a distinctpart of the same RAM. The client defines the size of the memory stacknecessary for correct execution of the client embedded software. Anattempt by one of the two software programs to access part of the RAMreserved for the other software will stop operation.

We will now describe a first embodiment of the invention in which theclient embedded software acts as a client driver software, withreference to FIG. 3.

Elements conventionally included in a radiocommunication module anddescribed above with reference to FIG. 2 (prior art) have the samenumeric references. Thus, the radiocommunication module 1 hosts andexecutes a main software 3 in particular comprising means 4 of executingAT commands.

Furthermore, according to the first embodiment of the invention and aspresented above with reference to FIG. 1, the radiocommunication module1 hosts and also executes a client embedded software 6 that acts as aclient driver software, and in particular comprises a client embeddedapplication 6 a, and an interface application 6 b.

Operation of this first embodiment of the invention may be summarized asfollows:

-   -   step “1”: The client embedded application 6 a calls a source        function (wm_atSendCommand”) to send one or several AT commands        to the execution means 4 (included in the main software). This        source function is presented in detail in the remainder of this        description;    -   step “2”: the interface application 6 b calls the appropriate        execution function(s) within the execution means 4 (included in        the main software 3);    -   step “3”: the execution means 4 execute the AT command(s);    -   step “4”: after execution, the execution means 4 send the AT        response(s) to the client embedded application 6 a (if the        previous send command was configured to do this);    -   step “5”: this or these responses are sent by the interface        application 6 b that calls the source function        (“wm_apmAppliParser”) for processing a message from the main        software, within the client embedded application 6 a. The        message that contains the above mentioned response(s) is a        parameter of this source processing function. This source        function is presented in detail in the remainder of the        description;    -   step “6”: the source processing function processes the response        within the client embedded application 6 a.

We will now present a second embodiment of the invention with relationto FIGS. 4 to 7, in which the client embedded software acts as theclient supervision software.

In this second embodiment, the radiocommunication module is notindependent (unlike in the first embodiment), but is controlled by aterminal equipment with which it cooperates. Therefore the configurationis the same as in prior art described above with relation to FIG. 2 (thesame elements are marked with the same numeric references). In otherwords, a client external application (client driver software) 2 sends ATcommands to a main software 3, so that they can be executed by the mainsoftware 3.

According to the second embodiment of the invention, theradiocommunication module 1 also hosts and executes a client embeddedsoftware 6 acting as client supervision software and in particularcomprising a client embedded application 6 and an interface application6 b. The client embedded software supervises execution (or lack ofexecution) of AT commands using execution means 4 included in the mainsoftware 6, transparently to the client external application 2.

The client embedded software 6 (supervision software) may decide to usethe following in particular, within the radiocommunication module:

-   -   an AT command preparsing and processing mechanism for commands        sent by the client external application (client driver software)        2. Three variant embodiments of this mechanism are proposed, for        example, according to which the main software 3 transmits the AT        commands that it receives; either to the execution means 4 only        (first variant), or to the client embedded software 6 only        (second variant) or to both (third variant);    -   an AT response preparsing and processing mechanism, resulting        from the execution of AT commands by the execution means 4        (included in the main software 3). For example, three variant        embodiments of this mechanisms are proposed by which AT        responses generated by the main software 3 are transmitted only        to the client external application 2 (first variant), or only to        the client embedded software 6 (second variant), or to both.

It will be noted that the first variant of each of the two mechanismsmentioned above (for AT commands and for AT responses respectively)means that the client embedded software 6 may decide to be completelypassive at some times. Therefore, they correspond to conventionaloperation of the radiocommunication module, as described above withrelation to FIG. 2, and are not described again.

We will now describe the second variant of the AT command preparsing andprocessing mechanism, which enables the client embedded software 6 tofilter AT commands originating from the client external application 2,with reference to FIG. 4.

Operation of this second variant of the AT command preparsing andprocessing mechanism can be summarized in two phases done in sequence,namely:

-   -   a prior phase in which the client external application 2 selects        the (second) AT command preparsing policy, according to which AT        commands are forwarded only to the client embedded software 6,        and,    -   a processing phase according to the “second” selected command        preparsing policy, to process AT commands sent by the client        external application 2.

The preliminary phase to select the second AT command preparsing policycomprises the following steps:

-   -   step “1”: the client embedded application 6 a calls a source        function (“wm_at_CmdPreParserSubscribe”) for registration with        the main software 3 to an AT command preparsing service, with a        parameter for this registration function that indicates the        choice of the second AT command preparsing policy. This source        function is presented in detail in the remainder of this        description;    -   step “2”: the interface application 6 b calls the appropriate        execution function(s) in the main software 3, that are functions        for making the registration to the AT command preparsing        service;    -   step “3”: the main software 3 prepares the registration        requested by the client embedded application 6 a, through the        interface application 6 b.

For simplification reasons, it is assumed in the rest of thisdescription (and as shown in FIG. 4), that the function(s) for makingthe registration to the AT command preparsing service are included inthe means 4 of executing AT commands, within the main software 3.

Also for simplification reasons, it is assumed in the rest of thedescription (and as shown in FIG. 4) that the command preparsing means(discussed below) are included within the AT command execution means 4,within the main software 3.

The AT command processing phase includes the following steps:

-   -   step “4”: the client external application 2 sends an AT command        to the main software 3;    -   step “5”: the serial link 5 sends the AT command to command        preparsing means, included in the execution means 4 (themselves        included in the main software 3) and operating according to the        second AT command preparsing policy (selected during the        previous phase);    -   step “6”: the AT command is transmitted only to the client        embedded software 6, without being executed by the execution        means 4;    -   step “7”: the AT command is sent by the interface application 6        b that calls the (“wm_apmAppliParser”) source function for        processing a message from the main software, within the client        embedded application 6 a, in this case configured by a message        that contains the AT command and that indicates that it is the        “original” AT command. This source function is described in        detail in the remainder of the description;    -   step “8”: the source processing function within the client        embedded application 6 a processes the AT command.

For example, this processing consists of resending the AT command toexecution means 4 (using the mechanism corresponding to the firstembodiment of the invention, described above in relation to FIG. 3). Itmay also consist of the arbitrary supply of a response by the clientembedded software 6 itself, without the AT command being executed. Inthis case, the client embedded software 6, for example, takes account ofat least one item of information about the AT command concerned (commandtype, nature of the parameter(s), etc.). In general, it is understoodthat the client embedded software 6 “filters” the AT command, regardlessof the processing done.

We will now describe the third variant of the AT command preparsing andprocessing mechanism that enables the client embedded software 6 to spyon AT commands from the client external application 2, in relation withFIG. 5.

Operation of this third variant of the AT command preparsing andprocessing mechanism can also be summarized as two successive phases,namely:

-   -   a preliminary phase in which the client external application 2        selects the “third” AT command preparsing policy, according to        which AT commands are sent not only to the client embedded        software 6, but also to the execution means (included in the        main software 3), and    -   a processing phase, according to the “third” selected command        preparsing policy, for processing AT commands sent by the client        external application 2.

Operation of this third variant is only very slightly different fromoperation of the second variant, essentially in that:

-   -   during step “1” of the preliminary phase, the client embedded        application 6 a selects the third (and not the second) AT        command preparsing policy;    -   during step “6” of the processing phase, the AT command is sent        to the execution means 4 and a copy of this AT command is sent        to the client embedded software 6;    -   during step “8” of the processing phase, within the client        embedded application 6 a, the source processing function        processes the copy of the AT command;    -   the processing phase also comprises a step “7” within which the        execution means 4 included in the main software 3 execute the AT        command.

We will now describe the second variant of the AT response preparsingand processing mechanism that the client embedded software 6 uses tofilter AT responses sent to the client external application 2, withreference to FIG. 6.

Operation of this second variant of the AT response preparsing andprocessing mechanism can be summarized in two phases done in sequence,namely:

-   -   a preliminary phase in which the client external application 2        selects the (second) AT response preparsing policy, according to        which AT responses generated by the main software 3 are sent to        the client embedded software 6 only;    -   a processing phase according to the “second” selected response        preparsing policy, to process AT responses generated by the main        software 3.

The preliminary phase to select the second AT response preparsing policycomprises the following steps:

-   -   step “1”: the client embedded application 6 a calls a source        function (“wm_atRspPreParserSubscribe”) for registration with        the main software 3 to an AT response preparsing service, with a        parameter for this registration function that indicates the        choice of the second AT response preparsing policy. This source        function is presented in detail in the remainder of this        description;    -   step “2”: the interface application 6 b calls the appropriate        execution function(s) in the main software 3, called functions        for making the registration to the AT response preparsing        service;    -   step “3”: the main software 3 prepares the registration        requested by the client embedded application 6 a, through the        interface application 6 b.

For simplification reasons only, in the remainder of the description (asshown in FIG. 6), it is assumed that the function for making aregistration to the AT response preparsing service, within the mainsoftware 3, is included within the AT command execution means 4.

Also for simplification reasons only, it is assumed in the remainder ofthe description (and as shown in FIG. 6) that the response preparsingmeans (discussed below) are included in the AT command execution means4, within the main software 3.

The AT response processing phase comprises the following steps:

-   -   step “4”: the client external application 2 sends an AT command        to the main software 3;    -   step “5”: the serial link 5 sends the AT command to the        execution means 4 (included in the main software 3);    -   step “6”: the execution means 4 execute the AT command and        generate an AT response;    -   step “7”: response preparsing means, included in the execution        means 4 and operating according to the second AT response        preparsing policy (selected in the previous phase) send the AT        response to the client embedded software 6;    -   step “8”: the AT response is sent by the interface application 6        b that calls the source function (“wm_apmAppliParser”) within        the client embedded software 6 a and provided to process a        message from the main software, in this case configured        particularly by a message that contains the AT response and that        indicates that it is the “original” AT response;    -   step “9”: the source processing function processes the AT        response, within the client embedded application 6 a. In this        case, this is called “filtering” of AT responses by the client        embedded software.

We will now describe the third variant of the AT response preparsing andprocessing mechanism that the client embedded software 6 uses to spy onAT responses sent to the client external application 2, with referenceto FIG. 7.

Operation of this third variant of the AT response preparsing andprocessing mechanism can also be summarized as two successive phases,namely:

-   -   a preliminary phase in which the client external application 2        selects the (third) AT response preparsing policy, according to        which AT responses are retransmitted not only to the client        embedded software 6, but also to the client external application        2, and    -   a processing phase according to the (third) selected response        preparsing policy, for processing AT responses generated by the        main software 3.

The main differences between the operation of this third variant andoperation of the second variant are that:

-   -   during step “1” of the preliminary phase, the client embedded        application 6 a selects the third (and not the second) AT        response preparsing policy;    -   during step “7” of the processing phase, the AT response is sent        to the client external application 2 and a copy of this AT        response is sent to the client embedded software 6;    -   during step “9” in the processing phase, the source processing        function processes the copy of the AT response, within the        client embedded application 6 a;    -   the processing phase also includes a step “8” during which the        response is sent through the serial link 5, and a step “9”        during which the client external application 2 receives and        processes the response.

Appendix 1 contains a detailed presentation of some of the sourcefunctions on which the client embedded application is based.

For example, Appendix 2 contains an example application of an embeddedapplication written in the C language, the objective of which is to sendan ATI3 command three seconds after each initialisation and to writeobjects in Flash memory.

Optionally, for the purposes of this invention, it is also possible touse at least one of the following additional AT commands in addition tostandard AT commands:

-   -   command to load a client software (AT+WDWL) to enable the client        external software to load a new client software into the        radiocommunication module;    -   deactivate command (AT+WOPEN) enabling the client external        software to deactivate the client embedded software.

APPENDIX 1 Detailed Presentation of Some Source Functions on Which theClient Embedded Application is Based

A1) “wm_apmAppliParser”

Function for processing a message from the main software. The messageforming parameter of the processing function in particular contains anAT command or a response to an AT command.

Exact name:

-   bool wm_apmAppliParser(wm_apmMsg_t*Message);    Parameters:-   Message    The message structure is different for each type of received    message:

Typedef struct {   S16 MsgTyp;   /* “MsgTyp” is a received message typeto determine   the associated structure of the message body */  wm_apmBody_t  Body;  /*  “Body” is a specific   message body */ }wm_apmMsg_t; Values of “MsgTyp”: WM_AT_SEND_RSPThe message contains a response to an AT command previously sent to themain software by the client embedded software

-   WM_AT_UNSOLICITED    The message contains an unsolicited AT command-   WM_AT_CMD_PRE_PARSER    The message contains an AT command sent by a client external    software through the main software.-   WM_AT_RSP_PRE_PARSER    The message contains an AT response resulting from the main software    executing an AT command originating from an external application.-   WM_OS_TIMER    The message is sent on expiration of a timeout    The structure of the body is:

typedef union {   /* The following includes all specific structures  associated with “MsgTyp” */ message types   /* WM_AT_SEND_RSP */  wm_atResponse_t ATResponse;   /* WM_AT_UNSOLICITED  */  wm_atUnsolicited_t ATUnsolicited;   /* WM_AT_CMD_PRE_PARSER  */  wm_atCmdPreParser_t ATCmdPreParser;   ;/* WM_AT_RSP_PRE_PARSER   */  wm_atRspPreParser_t ATRspPreParser   /* WM_OS_TIMER  */  wm_osTimer_t  OSTimer; } wm_apmBody_t; Substructures of the body areas follows: Body for WM_AT_SEND_RSP:   typedef struct {    wm_atSendRspType_e Type;     u16 StrLength; /* Length of strData */    char StrData[1]; /* AT response     */   } wm_atResponse_t;  typedef enum {     WM_AT_SEND_RSP_TO_EMBEDDED,    WM_AT_SEND_RSP_TO_EXTERNAL,     WM_AT_SEND_RSP_BROADCAST   }wm_atSendRspType_e;   (see details of the “wm_atSendCommand” functionfor   the description of “wm_atSendRspType_e description   ”), Body forWM_AT_UNSOLICITED:   typedef struct {     wm_atUnsolicited_e Type;    u16 StrLength;     char StrData[1];   } wm_atUnsolicited_t;  typedef enum {     WM_AT_UNSOLICITED TO_EXTERNAL,    WM_AT_UNSOLICITED_TO_EMBEDDED,     WM_AT_UNSOLICITED_BROADCAST   }wm_atUnsolicited_e;   (see details of the “wm_atUnsolicitedSubscription”  function for the description of “wm_atUnsolicited_e   ”). Body forWM_AT_CMD_PRE_PARSER:   typedef struct {     wm_atCmdPreSubscribe_eType;     u16 StrLength;     char StrData[1]   } wm_atCmdPreParser_t;  typedef enum {     WM_AT_CMD_PRE_WAVECOM_TREATMENT, /*     Defaultvalue     */     WM_AT_CMD_PRE_EMBEDDED_TREATMENT,    WM_AT_CMD_PRE_BROADCAST   } wm_atCmdPreSubscribe_e;     (see detailsof the “wm_atRspPreParserSubscribe”     function for the description of    “wm_atCmdPreSubscribe_e”). Body for WM_AT _RSP_PRE_PARSER:   typedefstruct {     wm_atRspPreSubscribe_e Type;     u16 StrLength;     charStrData[1];   } wm_atRspPreParser_t;   typedef enum {    WM_AT_RSP_PRE_WAVECOM_TREATMENT /*     Default value     */    WM_AT_RSP_PRE_EMBEDDED_TREATMENT,     WM_AT_RSP_PRE_BROADCAST   }wm_atRspPreSubscribe_e;   (see details of the“wm_atRspPreParserSubscribe”   function for the description of  “wm_atRspPreSubscribe_e”). Body for WM_OS_TIMER:   typedef struct {    u8 Ident; /* Timeout identifier     */   } wm_osTimer_t;(see details of the “wm_osStartTimer” function for a description of“Ident”).Returned parametersThe return parameter indicates if the message is processed (TRUE) or not(FALSE).A2) “wm_atSendCommand”Function for sending at least one AT command to the main software, inwhich one parameter indicates the destination software (namely theclient embedded software and/or the client external software) of theresponse resulting from execution of this AT command.Exact name:

-   Void wm_atSendCommand (u16 AtStringSize    -   wm_atSendRspType_e Responsetype,    -   char *AtString,);        Parameters:-   AtString    This parameter may be any type of string of AT command using ASCII    characters. Several strings may be sent at the same time.-   AtStringSize    Size of the previous parameter: AtString.-   ResponseType    Response type

Typedef enum  {   WM_AT_SEND_RSP_TO_EMBEDDED,  /* Default value */  WM_AT_SEND_RSP_TO_EXTERNAL,   WM_AT_SEND_RSP_BROADCAST }wm_atSendRspType_e;

-   -   WM_AT_SEND_RSP_TO_EMBEDDED    -   All responses are redirected to the client embedded application.        This is the default mode.    -   WM_AT_SEND_RSP_TO_EXTERNAL    -   All responses are redirected to the client external application        (PC).    -   WM_AT_SEND_RSP_BROADCAST    -   All responses are redirected (broadcast) to the client embedded        application and the client external application (PC).        A3) “wm_AtUnsolicitedSubscription”        Registration function with the main software to a service for        reception of unsolicited AT commands, in which one parameter        indicates the destination software (namely the client embedded        software and/or the client external software), to which each of        the unsolicited AT commands must be broadcast.        Exact name:

-   Void wm_atUnsolicitedSubscription(wm_atUnsolicited_e Unsolicited);    Parameters:

-   Unsolicited    This parameter describes actions carried out when an unsolicited AT    command arrives.

Typedef enum   WM_AT_UNSOLICITED_TO_EXTERNAL,  /* Default value   */  WM_AT_UNSOLICITED_TO_EMBEDDED,   WM_AT_UNSOLICITED_BROADCAST, }wm_atUnsolicited_e;

-   -   WM_AT_UNSOLICITED_TO_EXTERNAL    -   All unsolicited commands will be broadcast to the client        external application (PC) (default mode).    -   WM_AT_UNSOLICITED_TO_EMBEDDED    -   All unsolicited commands will be broadcast to the client        embedded application.    -   WM_AT_UNSOLICITED_BROADCAST    -   All unsolicited commands will be broadcast to the client        external application (PC) and the client embedded application.        A4) “wm_atCmdPreParserSubscribe”        Registration function with the main software to an AT command        preparsing service, in which a parameter indicates the        destination application(s) (namely the main software and/or the        client embedded software) to which each AT command originating        from an external application must be directed.        Exact name:

-   Void wm_atCmdPreParserSubscribe (wm_atCmdPreSubscribe_e    SubscribeType);    Parameters

-   SubscribeType    This parameter describes the action carried out when an AT command    arrives

Typedef enum  WM_AT_CMD_PRE_WAVECOM_TREATMENT, /* Default  value  */ WM_AT_CMD_PRE_EMBEDDED_TREATMENT,  WM_AT_CMD_PRE_BROADCAST, }wm_atCmdPreSubscribe_e;

-   -   WM_AT_CMD_PRE_WAVECOM_TREATMENT    -   The client embedded application does not want to filter (or spy)        commands sent by the client external application (default mode).    -   WM_AT_CMD_PRE_EMBEDDED_TREATMENT    -   The client embedded application wants to filter commands sent by        the client external application.    -   WM_AT_CMD_PRE_BROADCAST    -   The client embedded application wants to spy on commands sent by        the client external application.        A5) “wm_atRspPreParserSubscribe”        Registration function with the main software to an AT response        preparsing service, in which a parameter indicates the        destination software (namely the client external software and/or        the client embedded software) to which each AT command        originating from an external application must be directed.        Exact name:

-   Void wm_atRspPreParserSubscribe (wm_atRspPreSubscribe_e    SubscribeType);    Parameters

-   SubscribeType    This parameter describes the action carried out when an AT command    arrives

Typedef enum  WM_AT_RSP_PRE_WAVECOM_TREATMENT, /* Default  value  */ WM_AT_RSP_PRE_EMBEDDED_TREATMENT,  WM_AT_RSP_PRE_BROADCAST, }wm_atRspPreSubscribe_e;

-   -   WM_AT_RSP_PRE_WAVECOM_TREATMENT    -   The client embedded application does not want to filter (or spy)        responses sent to the client external application (default        mode).    -   WM_AT_RSP_PRE_EMBEDDED_TREATMENT    -   The client embedded application wants to filter responses sent        to the client external application.    -   WM_AT_RSP_PRE_BROADCAST    -   The client embedded application wants to spy on responses sent        to the client external application.        A6) “wm_atSendRspExternalApp”        Function to send at least one response to the client external        software, through the main software. This function can only be        used if a prior registration has been made to the response        preparsing service, in particular including redirection of a        copy of responses to the client embedded software.        Exact name:

-   Void wm_atSendRspExternalApp (u16 AtStringSize,    -   Char *AtString,);        Parameters:

-   AtString    May be any type of AT response string, in ASCII characters.

-   AtStringSize    Size of the previous parameter: AtString    A7) “DataFlowService”    Function to send and/or receive data by the client embedded    software, through the main software, after a data communication has    been set up.    A8) “wm_osStartTimer”    Function to start a timeout, a parameter of the said starting    function indicating which timeout is to be started.    A9) “wm_osStopTimer”    Function to stop a timeout, a parameter of the said stop function    indicating which timeout is to be stopped.

APPENDIX 2 EXAMPLE CLIENT EMBEDDED APPLICATION/***************************************************************************/ /* File : Appli.c *//*-------------------------------------------------------------------------*/ /* Object : Customer application */ /* This program waits 3 seconds,send a ATI3 command to */ /* software version. It starts a cyclic timerof 3 seconds */ /* and writes an object in Fash with a value 0. */ /*Every 3 seconds, it reads object value, display it, */ /* increments andrewrites it in Flash. */ /* */ /* contents : Customer main procedures *//* */ /* Change : *//*-------------------------------------------------------------------------*/ /* Date Author Modification *//*-------------------------------------------------------------------------*/ /* 26/12/00 FCA Creation *//***************************************************************************/ #include “wm_types.h” #include “wm_apm.h” #include “utils.h” #defineTIMER_INIT  01 #define TIMER_CYCLIC 02 #define OBJECT_ID  0x1 charwm_apmCustomStack[1024]; const u16 wm_apmCustomStackSize =sizeof(wm_apmCustomStack);/***************************************************************************/ /* Function : wm_apmAppliInit *//*-------------------------------------------------------------------------*/ /* Objet : Customer application initialisation */ /* */ /* Return :*/ /* *//*-------------------------------------------------------------------------*/ /* Variable Name IN OUT GLB Utilisation *//*-------------------------------------------------------------------------*/ /* InitType Application start mode reason *//***************************************************************************/ void wm_apmAppliInit (wm_apmInitType_e InitType) {   // Trace : Level10   wm_osDebugtrace(10, “Init : Start timer” );   // Start a timer for3 seconds   wm_osStartTimer (TIMER_INIT,FALSE, 30); }/***************************************************************************/ /* Function : wm_apmAppliParser *//*-------------------------------------------------------------------------*/ /* Objet : Customer task body */ /* */ /* Return : */ /* *//*-------------------------------------------------------------------------*/ /* Variable Name IN OUT GLB Utilisation *//*-------------------------------------------------------------------------*/ /* pMessage Message sent by real time kernel *//***************************************************************************/ bool wm_apmAppliParser (wm_apmMsg_t * pMessage) {   char strCommand[] = “ATI3\r”; // don't forget ‘\r’ at the end   u16 u16DataLen;   boolbRat;   char strTraceMsg[50];   char strData;   switch(pMessage->MsgTyp)   {     case WM_OS_TIMER :       switch(pMessage->Body.OSTimer:Ident)       {         case TIMER_INIT: // Timerarmed in wm_apmAppliInit           wm_osDebugTrace(10, ‘TIMER_INIT’ );          // Result will be visible in the AT terminal window          wm_atSendCommand(wm_strlan(strCommand)+1,              WM_AT_SEND_RSP_TO_EXTERNAL, strCommand);           //Write object for the first time           strData = 0x30;           bRat= wm_osWriteFlashData(OBJECT_ID, sizeof(char),                 &strData);           if (bRat)             wm_osStartTimer (TIMER_CYCLIC,TRUE,30);           else             wm_osDebugTrace(10, “wm_osWriteFlashDatafailed” );           break:         case TIMER_CYCLIC:          wm_osDebugTrace(10, “TIMER_CYCLIC” );           // Readobject, increment value, rewrite object           u16DataLen =wm_osGetLenFlashData(OBJECT_ID);           u16DataLen =wm_osReadFlashData(OBJECT_ID, u16DataLen,                   &strData ):          if (u16DataLen)           {             // Print object afterread             wm_strcpy(strTraceMsg, “Value :”);            strTraceMsg(wm_strlen(strTraceMsg)) = strData;            strTraceMsg(wm_strlen(strTraceMsg)+1 = ‘\0’;            wm_osDebugTrace(10, strTraceMsg );             //incrementit             strData--;             if (strData == 0x3A) strData =0x30;             bRat = wm_osWriteFlashData(OBJECT_ID, sizeof(char),                  &strData );             if (!bRet)             wm_osDebugTrace(10, “wm_osWriteFlashData failed” );          }           else             wm_osDebugTrace(10, “Read 0 byte”);           break;         default;           break;       }      default;         break;   }   return TRUE; }

1. Radiocommunication device hosting and executing a main softwareapplication that in particular performs radiocommunication functions,the said main software application comprising execution means forexecuting driver commands sent to the main software application by atleast one client driver software application and belonging to apredetermined set of driver commands, wherein the saidradiocommunication device also hosts and executes at least one clientsoftware application, called client embedded software, and wherein theclient embedded software application and the main software applicationcomprise enabling means for enabling the client embedded softwareapplication to perform at least one of the following two roles: a roleof a client driver software application sending driver commands to themain software application, and receiving responses from the mainsoftware application resulting from the execution of some of the drivercommands; and a role of a client supervision software application,managing execution of driver commands sent by a client driver softwareapplication, called a client external software application, hosted onand executed by terminal equipment cooperating with theradiocommunication device.
 2. Radiocommunication device according toclaim 1, wherein the following features are provided to enable theclient embedded software application to act as client driver softwareapplication: the client embedded software application comprises sendingmeans for sending driver commands to the execution means included in themain software application; the main software application comprisessending means for sending responses resulting from the execution of somedriver commands by the execution means included in the main softwareapplication, to the client embedded software application; and the clientembedded software application comprises processing means for processingresponses sent to it by the main software application. 3.Radiocommunication device as claimed in claim 1, wherein the followingfeatures are provided to enable the client embedded software applicationto act as client supervision software application: the main softwareapplication comprises preparsing means for preparsing commands as afunction of a determined preparsing policy, so as to transmit drivercommands from the client external software application to the clientembedded software application and/or to the execution means contained inthe main software application; and the client embedded softwareapplication includes processing means for processing driver commandsswitched to it by the said preparsing means.
 4. Radiocommunicationdevice according to claim 3, wherein the client embedded softwareapplication comprises selecting means for selecting a command preparsingpolicy applied by the said preparsing means, among a set of preparsingpolicies including: driver commands originating from the client externalsoftware application are sent only to the execution means within themain software application; driver commands originating from the clientexternal software application are sent only to the client embeddedsoftware application; and driver commands originating from the clientexternal software application are sent to the execution means within themain software application and to the client embedded softwareapplication.
 5. Radiocommunication device as claimed in claim 3, whereinthe said command processing means comprise at least one decision foreach command, belonging to the group including: send the driver commandto the execution means included in the main software application, theclient embedded software application comprising sending means forsending driver commands to the execution means for this purpose; andsupply or do not supply a response, only as a function of at least oneitem of information about the command, without executing the command,the client embedded software application comprising sending means forsending the response to the client external software application forthis purpose through the main software application. 6.Radiocommunication device as claimed in claim 1, where in order toenable the client embedded software application to act as clientsupervision software application: the main software applicationcomprises preparsing means for preparsing responses as a function of adetermined response preparsing policy, so as to transmit responsesresulting from the execution of some driver commands by the executionmeans included in the main software application, to the client embeddedsoftware application and/or to the client external software application;and the client embedded software application comprises processing meansfor processing responses switched to it by the said response preparsingmeans.
 7. Radiocommunication device according to claim 6, wherein theclient embedded software application comprises selecting means forselecting the response preparsing policy applied by the said responsepreparsing means, among a set of response preparsing policies including:responses originating from the execution means are transmitted only tothe client external software application; responses originating from theexecution means are transmitted only to the client embedded softwareapplication; and responses originating from the execution means aretransmitted to the client embedded software application and to theclient external software application.
 8. Radiocommunication device asclaimed in claim 6, wherein it is included within a device belonging tothe following group: radiocommunication terminals; devices other thanradiocommunication terminals necessitating a wireless communicationfeature; and modems.
 9. Radiocommunication device as claimed in claim 1,wherein the said main software application comprises at least one mainapplication particularly based on a set of execution functions, eachenabling the execution of at least one of the said driver commands, inthat the said client embedded software application comprises a clientapplication particularly based on a set of source functions, eachenabling sending or receiving driver commands or responses to drivercommands, to or from the main application, and in that the main softwareapplication and/or the said client embedded software applicationcomprise an application interface used to interface the said sourcefunctions with the said execution functions.
 10. Radiocommunicationdevice as claimed in claim 1, wherein the said client embedded softwareapplication comprises a client application, particularly based on a setof source functions, each enabling sending or receiving driver commandsor responses to driver commands, to or from the main application, and inthat the said set of source functions particularly comprises a functionfor processing a message originating from the main software application,the said message being a parameter of the said processing function. 11.Radiocommunication device according to claim 10, wherein the structureof the said message forming a parameter of the said processing functioncomprises: a first field containing information related to a type of thesaid message; a second field containing a specific body of the saidmessage.
 12. Radiocommunication device according to claim 11, whereinthe said message type belongs to the group comprising: messagecontaining a response to a driver command previously sent to the mainsoftware application by the client embedded software application;message containing an unsolicited driver command; message containing adriver command sent by a client external software application throughthe main software application; message containing a response resultingfrom execution of a driver command by the main software application; andmessage sent on expiration of a timeout.
 13. Radiocommunication deviceas claimed in claim 10, wherein the said set of source functions alsocomprises at least a source function belonging to the following group: asending function for sending at least one driver command to the mainsoftware application, a first parameter of the said sending functionbeing the said at least one driver command, a second parameter of thesaid sending function indicating a destination software application towhich the response resulting from execution of the said driver commandis sent, namely the client embedded software application, and/or theclient external software application; a registration function with themain software application to a service for reception of unsoliciteddriver commands, one parameter of the said registration functionindicating the destination software application to which each of theunsolicited driver commands is to be redirected, namely the clientembedded software application, and/or the client external softwareapplication; a registration function with the main software applicationto a driver command preparsing service, in which a parameter of the saidregistration function indicates the destination application(s), namelythe main software application and/or the client embedded softwareapplication to which each driver command originating from the clientexternal software application must be directed; a registration functionwith the main software application to a response preparsing service, inwhich a parameter of the said registration function indicates thedestination application(s), namely the client external applicationand/or the client embedded software application to which each responseresulting from the execution of a driver command by the main softwareapplication, must be directed; and a function for sending at least oneresponse to the client external software application, through the mainsoftware application, a parameter of the said sending function being thesaid at least one response.
 14. Radiocommunication device as claimed inclaim 1, wherein the client embedded software application and the mainsoftware application each use a distinct part of a RAM, and an attemptby one of the two software application programs to access part of theRAM reserved for the other software application will stop operation. 15.Radiocommunication device as claimed in claim 1, wherein the said set ofdriver commands is a set of standard AT commands.
 16. Radiocommunicationdevice according to claim 15, wherein the said set of driver commandscomprises an additional AT command for loading a client softwareapplication, enabling the client external software application to load anew client software application into the radiocommunication device, inaddition to standard AT commands.
 17. Radiocommunication device asclaimed in claim 15, wherein the said set of driver commands comprisesan additional AT command called a deactivate command enabling the clientexternal software application to deactivate the client embedded softwareapplication, in addition to standard AT commands.
 18. Process forimplementing a client software application for driving aradiocommunication module, the process comprising: hosting and executinga main software application on the radiocommunication module, whereinthe main software application performs radiocommunication functions,wherein the said main software application executes driver commands sentto the main software application by the said client driver softwareapplication and belonging to a predetermined set of driver commands;hosting and executing at least one client software application, calledthe client embedded software application, on the radiocommunicationmodule, wherein the client embedded software application and the mainsoftware application dialogue with each other such that the clientembedded software application performs at least one role of a group ofroles comprising: the role of the said client driver softwareapplication sending driver commands to the main software application,and receiving responses from the main software application resultingfrom the execution of some of the driver commands; and the role of aclient supervision software application, managing execution of drivercommands sent by the said client driver software application, the saidclient driver software application called the client external softwareapplication being hosted on and executed by terminal equipmentcooperating with the radiocommunication module.